1. Field of the Invention
The present invention relates to a computer-implemented system that supports the effective coordination of geographically and/or functionally distributed human tasks (i.e., operations, processes, and decision making, etc.) as well as computer-programmed tasks by developing and managing, over the Web, networked information contents that support those tasks.
2. Prior Art
Information contents which are constructed and viewed on the Web are represented in Web-standard languages such as HTML (Hyper Text Markup Language) and XML (Extensible Markup Language). Units of information that are written in such languages are called “Web documents”. The most important characteristics of Web documents are their ability for information contents in these documents to be decomposed in a tree-like hierarchical structure, and for each component in such a decomposition to have a semantic description and attributes through a syntactic construct called a “tag”. While tags in HTML are for layout interpretation only and not extensible, tags in XML are extensible and can accept any interpretations which the user defines. In HTML and XML, information contents that can be identified as decomposed components via tags are called “elements”.
With reference to FIG. 1 below, we will illustrate elements and their hierarchical structure in XML. In FIG. 1, the part <CompanyName>ABC Paper Mill </CompanyName>, for instance, is an example of element. <CompanyName>is an open tag, and </CompanyName>is a closed tag. An element can have its own internal tree structure, and an element can contain another element therein. In this case, the latter element is called a “sub-element” of the former. For instance, in FIG. 1, the part beginning with the open tag <Work>and ending with the closed tag </Work>is an example of an element having its own internal structure. Elements such as <CompanyName>ABC Paper Mill </CompanyName>and the part beginning with <FatherContactAtWork Cname=“C1”>and ending with </FatherContactAtWork>are examples of sub-elements of the <Work>element. Furthermore, the <FatherContactAtWork Cname=“C1”>sub-element has its own sub-elements such as <DirectPhone>025 432 3229</DirectPhone>. A sub-element of a sub-element of an element is also a sub-element of this element. For instance, <DirectPhone>025 432 3229</DirectPhone>is also a sub-element of the <Work>element. In XML, various attributes can be defined for the elements. More specifically, an attribute can be defined for an element in its open tag in the form Attribute Name “Attribute Value”. In FIG. 1, through the open tag <FatherInfo DateUpdated=“Feb. 1, 2000”>, the “FatherInfo” element is given an attribute, “DateUpdated”, and its value, “Feb. 1, 2000”.
Web-standard languages such as HTML support “links” that relate elements of Web documents, and a network of information contents can be developed via such links. Moreover, XML and its related standards such as XLinks support linking capabilities which are far superior to those that are offered in HTML.
However, links are a mechanism for moving from one piece of information content to another, and are not intended to capture “dependency relationships” that might exist between such pieces of information contents. A critical difference between links and dependency relationships is that in dependency relationships, there is the notion of “interpretation” between related pieces of information contents. For instance, an engineer who is responsible for the development of a product is likely to have a certain specific use of sales data pertaining to the product. Thus, it is desirable to analyze and customize the sales data for his intended use. If this analysis and customization can be captured computationally, the customized data functionally depends on the original sales data. It is not possible to directly represent such dependency relationships by using linking mechanisms of Web-standard languages such as XML or XLinks.
Currently, such dependency relationships are represented by using programming languages such as Java or scripting languages such as Java Script (from here on, we use the term “programming languages” to refer to scripting languages as well).
However, there are several problems and difficulties which are associated with representing dependency relationships by using programming languages. For instance:                Representational Independence: When precise representations of dependency relationships depend on particular programming languages, their representational independence from specific implementations is difficult to maintain. If the deployed programming language changes, the existing representations of dependency relationships may possibly become invalid.        Sharing: One must know a specific programming language sufficiently well in order to understand the precise definitions of dependency relationships that are given in the programming language. It is difficult to share dependency relationships and organizational knowledge which is captured in such dependency relationships.        Flexibility in maintaining and managing existing dependency relationships: Once dependency relationships get coded in a programming language, it will be more difficult to adjust and modify the dependency relationships, and, consequently, the resulting information system tends to be rigid.        Uniformity: Since there is no established, uniform representation format for dependency relationships, it is difficult to maintain uniformity in the representation of dependency relationships, and hence, it is also difficult to evaluate a chain of multiple dependency relationships. For instance, suppose we have information contents A, B and C. If we have different representation formats for a dependency relationship from A to B and another dependency relationship from B to C, we would have to have multiple evaluation environments, and it would be more difficult to evaluate the chain of relationships from A to C (via B) without interruptions.        Consistency: When no uniform representation format is established for dependency relationships, it will be difficult to maintain the consistency of entire information contents which are networked through such relationships. More precisely, the difficulty is with the consistent propagation of updates throughout the dependency chain of information contents whenever a change occurs in some part of the networked information contents.        
Now, we shift to the issue of interface for editing and viewing information contents over the Web. The notion of a “port” as a relay point or interface for information interchange has been around for a long time. For instance, a telephone is an example of a port, as well as email over the Internet. These are a kind of “general-purpose” ports in the sense that they receive unspecified information from unspecified sources. In contrast, with the advent of the Web, it is becoming increasingly feasible to construct ports that are specialized for particular needs. For instance, a company may have Web pages that are customized for individual clients, through which each client can obtain customized information or send his own order inquiries. These are beginning examples of “special-purpose” ports.
However, as the intended use of a port gets more specialized, so does the role of the port within the entire context of a task that the user of the port is expected to accomplish. In such cases, the user would have to have a collection of special-purpose ports to complete his task. However, a framework for organizing a collection of related ports that are intended to support a complete task has not been developed yet. For instance, a product development engineer, as in the example above, might need a port for receiving sales information from the sales department, a port for receiving information on production process from production lines, and also a port for sending information to production lines. We would need a framework for managing such a collection of ports as a coherently organized “port complex”, with its coherence stemming from the fact that all of these ports are intended to support a common task collectively.
At this point, the idea of building a port complex over the Web has not been systematically developed. The present practice of information interchange over the Web for the purpose of coordinating organizational tasks has the following technical difficulties and problems:                Layout discontinuity of related ports: For instance, in the case of placing orders over the Web, the port for sending orders and the port for receiving order confirmations should reside in the same port complex as they serve the same task of order-placing. However, in most cases, these two ports are represented as separate Web documents, and hence, the user needs to go back and forth between multiple documents in order to complete his task. In other words, the layout continuity of use-wise related ports has not been well established. The layout and operational “distance” between related ports should solely depend on the amount of information being presented in those ports.        Ineffective, mixed representation of related ports: A port complex has several aspects or features. They are, for instance, information contents in the complex, types of ports in the complex, input and control functions of ports, and the layout of the complex. If HTML is used to build a port complex, all of these aspects or features will be mixed in one file, and people with HTML knowledge would have to deal with all of those aspects or features. Obviously, this is not a very effective way of building a port complex. XML, on the other hand, separates information contents from layout presentation, and hence, port layout can be specified in a separate file by using a layout specification language such as XSL (Entensible Style Language). Even in a XML representation of a port complex, however, unless those aspects or features are well distinguished at least conceptually, disadvantages of HTML-based development would still persist.        